FIG. 3 shows the basic architecture of a mobile network. In a simplified view, a mobile network comprises of five domains:                User Equipment UE. Those may range from simple cellular mobile phones over smart phones to wireless notebooks        Radio Access Network RAN comprising of base stations, antennas, everything that is there to provide radio access        Mobile Core. This includes facilities necessary to handle user authentication and authorization, where user subscription data is stored (HSS home subscriber system)        Service Delivery Framework SDF. This comprises of servers for mobile operator content and services including content delivery functions like cashing.        Backend System. Here are the network management facilities and billing and charging systems.        
In addition, there are two edges—between RAN and core and between core and world wide services networks.
The RAN/core edge comprises facilities which are mobile network generation dependant, i.e. in a 2G network (GSM) those comprise of base station controllers BSC which control bundles of base stations (e.g. for paging), in case of 3G (UMTS) those are radio network controllers (RNC) with much more complexity (terminating parts of the radio layer, performing soft combining). In a 4G network (long term evolution, LTE) there is no edge function since the function split again changed significantly with packet based (IP or Ethernet) connections from base station to the core and all radio layers terminated in the base station (eNodeB) and with mobility management moving to the core network into Mobility Management Entity MME.
The core/services networks edge comprises entities which handle the communication between the mobile network and the outside world. Mobile Switching Centres (MSC) handle narrowband circuit switched voice traffic (and MSC-Servers and media gateways Voice-over-IP based communication, not shown in figure). Packet data access to/from services networks (internet) is handled by a GPRS Gateway Serving Node (GGSN) or by a Servicing/Packet Gateway (S/P-GW) in case of 4G LTE.
Edge nodes like RNC or GGSN are unique points in the network since all traffic (at least all packet data traffic, i.e. all internet traffic) runs through them. Due to their complexity their numbers are limited per network so that there are a few crucial topological points in the network which are single points of failure and which may become performance bottlenecks as traffic increases significantly (200 times in 10 years).
According to this simplified architecture, a broadband fixed network architecture can be drawn alike (no specific figure, but see upper part of FIG. 4). Here the Access Network can have a digital subscriber line (DSL) Access Multiplexer (DSLAM) as an edge node (which terminates the physical layer towards the DSL modems) and a Broadband Remote Access Server (BRAS) as a core/services network edge node.
Both core edge nodes—the GGSN (or S/P-Gateway, respectively) of a mobile network and the BRAS in case of a fixed network are quite comparable:                there exist only a few of them per network        they are gateways to the outside world for packed data        they are enriched with functionality as authentication, authorization, deep packet inspection (DPI), policy enforcement, etc.        most typically they are based on router platforms        they are problematic in terms of bottlenecks and single point of failure        
FIG. 4 shows a scenario where one operator runs both networks (fixed and mobile, e.g. Deutsche Telekom, Telefonica) with the upper part representing the fixed network and the lower part representing the mobile network. Furthermore, FIG. 4 shows cellular Femto cells H(e)NodeB which provide a cellular air interface in home or enterprise environments and which are IP-connected over a fixed access network (DSL). Cellular traffic from femto cells will be run through the wireline network through the BRAS to a Security Gateway (SecGW) which belongs to the mobile network. The SecGW allows to run VPN encrypted links between the mobile network and the H(e)NodeB so that all UE-Mobile Network-traffic is secured when running through third party networks. The triple BRAS, SecGW and GGSN shall be denoted as “converged/consolidated edge” further on (indicated by a dotted line in FIG. 4).
Core network functions and nodes can be classified in two categories: there are pure control plane functions exchanging signaling information and there are functions and nodes that have both—control functions and data forwarding. The first category is in the primary focus of network virtualization since those can be “tailored” such that they can run as one or several applications on top of virtual machines in a “cloud”. However, the edge nodes (e.g. GGSN, BRAS), due to their ambiguous nature (control and data forwarding) cannot be simply virtualized following pure data center principles—in pure IT data center setups there are no nodes that have this gateway function—thus data center technologies yet do not provide a suitable solution for gateway virtualization. But without virtualization of these edge nodes the virtualization of the mobile core remains unfinished, deficient and crippled—the full potential of network virtualization can not be applied.
The edge nodes (e.g. GGSN, BRAS) went through an evolution process. Especially mobile networks evolved from 2nd generation global system for mobile communication (GSM) over 3rd generation universal mobile telecommunication system (UMTS) to 4th generation LTE—and most real world mobile networks thus comprise of functionality and nodes of multiple generations. In order to allow quick market entry and in order to save costs, quite often existing nodes were amended with new functionality (rather than introducing new nodes). Key functionalities like mobility anchors, deep packet inspection, traffic shaping were preferably put onto those nodes which are located at central cross points in the network, as for example RAN/core edge or core/services network edge. During this evolution process those nodes have been enriched (or even overloaded) with functionality. This—to some extend may apply for the RNC, but especially for the GGSN and for the BRAS.
Now, in times of ever increasing traffic (100-300 times in 10 years) this problem becomes more and more urgent since router platforms cannot scale up in terms of performance as it would be necessary in terms of traffic increase—but reducing performance bottlenecks by putting more of these nodes to the network would require changes in the architecture: mobility anchors would have to move (GGSN) or authentication, authorization, and accounting (AAA) servers and management systems would have to be distributed (BRAS).
FIG. 7 shows some of the functions these nodes may provide.
The BRAS is a big access router which mediates between outside (internet) and inside (user) IP traffic. If it is edging a DSL network, most likely it terminates point-to-point protocol (PPP) (and/or PPP over Ethernet, PPPoE) connections from client users. PPP encapsulated authentication information is verified (RADIUS client) against a AAA (RADIUS) server. Upon successful authentication clients are most commonly assigned an IP address out of a pool provided by a Dynamic Host Configuration Protocol (DHCP) server requested by the BRAS' DHCP client function. In case of forwarding traffic to a remote BRAS or in case of receiving relayed traffic from a remote BRAS the BRAS employs layer-2-tunneling protocol (L2TP). In order to reduce overall traffic load the BRAS may also employ means of traffic shaping.
Alike, the GGSN is a giant remote access server connecting the cellular users to the outside IP world. By this it provides means for authorization (is the user allowed to use a service). In case users employ a specific service (access point number, APN, e.g. internet access) a packet-data-protocol (PDP)-context is stored in the GGSN. IP address dependant services access can additionally be performed by a service-selection-gateway (SSG) and user specific policies (e.g. bandwidth guarantee/limitation) can be enforced here. Also deep packet inspection can be employed e.g. to derive further IP address dependant billing information.
Finally, the SecGW has a simple functionality: it is the endpoint of virtual private network (VPN) tunnels. As there may be many of them, typically, a key issue is on performance rather than on complexity.
A major trend in telecommunications, also in mobile networks, especially in the core is to use data center technologies for applications. One motivation of that is to reduce total cost of ownership (TCO) since one platform (data center) can be used for many (most) applications that by today are often running on distinct network nodes. Furthermore, it allows a better scaling and more elasticity since applications can be invoked and terminated flexibly according to networking demands. FIG. 1 shows a typical setup of a data center and its management entities.
The data center itself comprises of hardware including multi core processing units and switching facilities (D-Switch in FIG. 1) to interconnect different processing units on the multiple blades in the multiple racks that make up a data center. The multiple computing parts will be equipped with an operating system (host OS, e.g. Linux) on which one or several virtual machines (VM) can be established. These VMs may be equipped with application software running on top of yet another operating system (guest OS, e.g. Linux, Windows). The control of the different VMs is done by a piece of e.g. HiperVisor (HV) middleware which acts as a mediator between the guest OS/VM and the host operating system hiding the virtual nature of the platform to the guest OS.
Virtual machines will be invoked/terminated and equipped with software images by a Infrastructure-as-a-service (IaaS) component, also denoted as Cloud Management System. On demand (of e.g. a cloud orchestration system) a specific software image (which may also include the guest OS) out of a list of software images that is stored in a database will be started on a virtual machine. The selection of the VM is done and controlled by this entity.
The Cloud Orchestration Function, e.g. NSN Cloud Framework CFW, stores templates for specific software that shall be deployed in a network which are stored in yet another database. Those templates comprise e.g. information about how many applications make up a network function (e.g. three applications together form a voice communication server VCS), which of the images that are stored in the IaaS database do reflect this application(s), the starting order of the different applications, identifiers (IDs) that allow to identify running applications and more. Per screen level command or triggered by and external network control (e.g. via http based interface) a new application can be started/stopped/modified and monitored. The Cloud Orchestration System will communicate with the IaaS or cloud management system, respectively, and directly/indirectly with the application. Yet those interfaces are still subject of standardization, current solutions employ Quantum and Eucalyptus and derivates of those.
Another trend is gaining momentum in communication service provider (CSP) networks: software defined networking (SDN)—i.e. decoupling of data forwarding and control.
By today, typical nodes in transport networks comprise of specific functionalities. A router, for example, comprises of data switching fabriques which move data packets between the different I/O ports. But it also handles all the complex routing protocols like resource reservation protocol (RSVP), it holds routing tables and more. All the complex functionality and the switching is encapsulated in one box. Another example would be a carrier Ethernet switch, providing data forwarding and control on layer 2. And more and more multilayer switches are used in transport networks providing (generalized) multi protocol label switching ((G-)MPLS) functionality which on top of the before mentioned router or switch functionality provide MPLS/G-MPLS signaling capability. Bottom line, depending for what purpose a transport node is used it is more or less complex providing data forwarding and control function in one monolithic node.
The basic idea of SDN is to decouple control functions from data forwarding functions, in other words, everything that makes a router being a router and everything that makes a switch being a switch is taken out of a node, let's call the remaining part network element (NE) and put the taken out part into a controller. What will be remaining in the NE is pure data forwarding functionality. With this philosophy, routers, switches, MPLS nodes would all have a similar look-alike NE for data forwarding, and a specific control element (which may be outside the box) which makes it a router or a switch or whatsoever.
FIG. 2 describes some principles of SDN.
At the bottom of the picture, a NE providing pure data forwarding functionality is shown. It comprises of the switching hardware (data path) which provides I/O ports, some pieces of software to allow configuration, a flow table which contains port based rules for data forwarding.
Here is a description of how to handle a packet depending on e.g. header information. For example, a rule may be that incoming packets on port 0 will be analyzed such that depending on what information is in the header, the packet shall be forwarded to port 2 or 3. These rules, which are stored in a flow table, can be passed to the NE from a controller which may reside outside the box (denoted as SDN control). For that, a protocol for exchange must be specified and both, the controller and the NE (SDN client) must be able to mutually understand the protocol. A most prominent representative for an SDN control protocol is OpenFlow as specified in the Open Network Foundation (ONF). Another known representative is ForCES.
This way and with additional means a whole eco system for sharing transport equipment can be built up. NEs and controller can be cascaded and access can be limited. Introducing FlowVisors will limit access to certain parts of a Flow Table (e.g. ports 0 to 3). Controllers themselves may act as proxies to other controllers. Finally, SDN controllers may provide a northbound interface (i/f) to applications. By this, applications may acquire network resources via this interface in an abstracted way, e.g. “connectivity between topological point A and topological point B with a given bandwidth”. SDN controllers may then instruct NEs out of a pool of NEs where there might be several options to solve the request—still hiding the network HW to the application by using this abstract interface.
The principle may be generalized:
If a node can be sufficiently characterized in a way that it comprises:                at least one port for incoming and outgoing packet data communication (Ethernet port);        software and hardware (Operating System, Ethernet backplane) that allows packet data transmission via this at least one port;        functions that modify incoming/outgoing data streams/flows (de/encryption, tunnel termination);        functions that use and/or modify information contained in the data stream (DPI),        
then, this node can be decomposed into (see FIG. 8):                a pure packet data forwarding engine comprising an commercial-off-the-shelf switch or router comprising                    multiple ports for incoming/outgoing packet data;            software and hardware that allows conveying data streams/flows between ports;            rules for conveying streams between ports based on information found in packed data headers (IP Header, Ethernet Header) stored in a database (flow table);            and interface that allows configuration and modification of these rules (resource manager slave);                        one or several nodes that do perform functions for modification of incoming/outgoing data streams (flow modification1/2);        one or several nodes that use and/or modify information contained in the data stream (function 1/2);        a node or entity that controls/modifies the rules stored in the database (resource manager master).        
The function of the packet data forwarding engine is very simple: packet header information of general ingress traffic will be analyzed (e.g. source, source/destination IP address, VPN encryption, etc.) and a rule is searched in the flow table. A rule may simply comprise information to which port this packet shall be forwarded. Packets will then be forwarded to the ports according to the rule. If no rule is found, packets may be forwarded to the general egress.
The functions of the other nodes either comprise simple flow modification functions (e.g. VPN en/decryption) or higher layer functions (applications) which may even completely change the information in the flow—they receive an incoming stream, analyze and/or modify it and put the result into an outgoing stream back to the packet data forwarding engine.
FIG. 9 shows an implementation example of some functions of gateways according to these principles. As may be seen from the figure, by this architecture, several gateway types like GGSN, SecGW, and BRAS may be combined into a single system.
In the centre, there is an OpenFlow enabled Ethernet switch. OpenFlow is an OpenSource standard which has been chosen for the implementation example due to its simplicity, however, any mechanism allowing control access to a data plane would do. The example bases on an Ethernet switch (layer 2), again due to its simplicity, however, the principles shown are valid for any layer.
The flow table can be modified via the OpenFlow protocol by any server that talks OpenFlow. Some exemplary functions are shown: PPP or PPPoE termination or handling (BRAS), VPN tunnel en/decryption (SecGW) and PDP context and DPI for the GGSN.
All incoming data from the RAN/DSL access network run through the general ingress port of the switch. If header analysis results in there is a PPP encapsulation, the according rule in the flow table is forwarding these packets (with a PPP encapsulation) to a port where a PPP handler is connected (PPPoE termination). The resulting outbound stream of this PPP handler is connected to another port of the switch, now the incoming stream has no encapsulated PPP frames. If header analysis of this new incoming stream results in that packets are VPN encrypted (e.g. because packets came from a femto base station, another rule will convey those packets to yet another handler which does decryption (SGW VPN en-decryption) and feeds its outgoing stream again to the switch. This stream again will be header-analyzed. Then another rule could imply that the target IP address of the packet requires deep packet inspection, e.g. to derive further billing information and so forth.
Finally, if no further rule is found, traffic will be conveyed to the general egress port (e.g. to/from internet exchange).
Due to this packet flow, the decomposition principle according to SDN is also named “service chaining”.
The existing approaches to apply SDN are still too simple to address the problem of edge nodes properly. FIG. 5 shall help to illustrate the issue. Here is an example of how SDN could be applied to a typical network service scenario. At top level there is an application which uses two types of communication service, real time voice and best effort data. Imagine a shopping portal where you can browse in a shop while in parallel there is an ongoing voice over IP (VoIP) call with a hotline where you can ask questions. In a virtualized network, this application may request for connectivity to an SDN controller (which might be embedded in the application or not) using an abstract northbound interface. The request might comprise of “real time connection between A and B and best effort connection between A and C”. The SDN controller might then configure one or several NEs, the figure shows the configuration of one specific node. This NE might be shared between several SDN-controllers so that a FlowVisor will allow manipulations only on ports 0, 1 and 2 for this SDN-controller.
The SDN controller might manipulate the accessible part of the flow table such that incoming traffic on port 0 (which might comprise of real time voice traffic and best effort data traffic from the user) will be analyzed. If header information contains indication that VoIP is used (e.g. real time transport protocol (RTP) header found) then traffic shall be forwarded to a high performance part of the network (which in the example is accessible through port 1). All other traffic shall be forwarded to port 2. This is a typical deployment scenario for SDN enabled nodes and here the dilemma of this approach becomes obvious: the separation into control and data forwarding made the NE turn into a stone stupid forwarding engine that only allows relaying data packets from one port to another without further manipulation. Because of this limitation, this sort of NE shall be further denoted as “NE class 0”. This may be well suitable for pure transport packet transmission but not for relaying transport user data information that require specific interworking on the forwarding plane. Examples for necessary U-Plane data modifications are:                GPRS tunneling protocol (GTP) tunnel handling        Policy enforcement/traffic shaping        Encryption        State full interworking, i.e. making forwarding dependant on authentication        
Current SDN concepts do not properly address these issues. E.g., edge nodes like S-GW and P-GW require this functionality: S- and P-Gateways to handle GTP tunnels and P-Gateways do policy enforcement.
According to a further approach, NEs are amended with additional functionality beyond pure packet forwarding, such as tunnel handling capabilities. FIG. 6 shows a node (NE) which is able to handle tunnels. Tunnels in this context mean that data packets may enveloped in another frame with a tunnel header and with the tunnel having endpoints (node A, node B). Typical examples for tunnels are GTP tunnels (as used in mobile core networks) or PPPoE encapsulation (as used in fixed DSL networks).
The extensions of such an NE (which turns them into a so-called “class 1 NE”) should comprise additional tunnelling rules that might be applied to tunnel types and/or ports. As an example, a NE shall terminate all GTP tunnels that come in through port 0, strip off tunnel frames and forward to port 1. In addition, all non-tunneled packets received through port 0 shall be supplied with tunnelling framings according to parameters given in the rules (e.g. tunnel end point address).
The SDN control protocol is thus be extended to allow transfer of tunnelling rules from the controller.
Correspondingly, a class 0 NE may be enhanced by capabilities of traffic shaping, policy enforcement, ciphering, deciphering, DPI, etc., or a combination of these capabilities. Accordingly, the SDN control protocol is extended to allow transfer of the corresponding rules from the controller. Different NEs connected to a SDN controller may belong to different classes (have different capabilities).
From an abstract point of view, thus, the functionality of a gateway is decomposed into three parts:
A: Application part (e.g. S-GW-App, P-GW-App). This comprises e.g. all signaling functions. Generally speaking, the application part is the software that interfaces logically to other signaling entities, i.e., an S-GW-App will communicate logically with mobility management entity (MME), eNodeB, and/or home subscriber server (HSS). Most preferably, the application part is designed in a way that it can run on top of a virtual machine in the cloud—then it may be added as another application running in the cloud alongside with MME, HSS and else.
C: Control Part (e.g. S-GW-Ctrl, P-GW-Ctrl). This is the control part (SDN-control) that has been stripped off the existing S-GW/P-GW node. It is used to steer the transport resources as described hereinabove. Most preferably, the control part is designed as an extension of an existing overall network controller—then it may be added to the SDN controller—or it simply is the SDN controller.
F: Network Element Part or Forwarding part (e.g. S-GW-NE, P-GW-NE). This is the data forwarding part of the formerly monolithic gateway node. It follows the principles of SDN (i.e. it can be steered by an SDN controller). Most preferably it is equipped with the adequate extensions described in chapter 4.
Accordingly, an architecture of a network element decomposed according to these principles is named A-C-F separation.